Automated Verification of Design Patterns with LePUS3

Specification and [visual] modelling languages are expected to combine strong abstraction mechanisms with rigour, scalability, and parsimony. LePUS3 is a visual, object-oriented design description language axiomatized in a decidable subset of the first-order predicate logic. We demonstrate how LePUS3 is used to formally specify a structural design pattern and prove (‗verify‘) whether any JavaTM 1.4 program satisfies that specification. We also show how LePUS3 specifications (charts) are composed and how they are verified fully automatically in the Two-Tier Programming Toolkit

On the Definition of Architecture, Design and Implementation

The terms architecture, design, and implementation are typically used informally in partitioning software specifications into three coarse strata of abstraction. But these strata are not well-defined in either research or practice and often overlap causing confusion and needless discussion. To remedy this problem we formally define two criteria: the Intension and the Locality Criteria, and show that the intuitive discrimination between the three terms architecture, design, and implementation is qualitative and not merely quantitative. We demonstrate that architectural styles are intensional and non-local; that design patterns are intensional and local; and that implementations are extensional and loca

The Architecture of Complexity Revisited: Design Primitives for Ultra-Large-Scale Systems

As software-intensive systems continue to grow in scale and complexity the techniques that we have used to design and analyze them in the past no longer suffice. In this paper we look at examples of existing ultra-large-scale systems—systems of enormous size and complexity. We examine instances of such systems that have arisen spontaneously in nature and those that have been human-constructed. We distill from these example systems the design primitives that underlie them. We capture these design primitives as a set of tactics— fundamental architectural building-blocks—and argue that to efficiently build and analyze such systems in the future we should strongly consider employing such building-blocks

A manifesto for energy-aware software

According to recent estimates, computing and communications could account for 20% of energy usage globally by 2025.1 This trend shows no sign of slowing. The annual growth in power consumption of Internet-connected devices is 20%. Data centers alone are now accounting for more than 3% of global emissions. Even if you are not worried about this trend on the mega scale, you are likely concerned with the power consumption of the devices in your pocket, on your wrist, and in your ears. Software, hardware, and network attributes all contribute to power usage, but little attention has been given to this topic by the information and communications technology (ICT) community

Demystifying Big Data Adoption: Beyond IT Fashion and Relative Advantage

There is a paradox in big data adoption: a peak of hype and simultaneously an unexpectedly low deployment rate. The present multiple case study research develops a Big Data Adoption (Big2) model that helps to explain this paradox and sheds light on the “whether”, “why”, and “how” questions regarding big data adoption. The Big2 model extends beyond the existing Relative Advantage and IT Fashion theories to include organizational, environmental, social variables as well as new psychological factors that are unique to big data adoption. Our analysis reveals that the outcome of big data adoption is indeterministic, which defies the implicit assumption of most simplistic “rational-calculus” models of innovation adoption: Relative Advantage is a necessary but not sufficient condition for big data adoption. Most importantly, our study uncovered a “Deployment Gap” and a “Limbo Stage” where companies continuously experiment for a long time and do not proceed to deployment despite the intent to adopt big data. As a result there are four big data adoption categories: Not adopting, Experimented but Not Adopting, Not Yet Deployed, Deployed. Our Big2 model contributes to provide a Paradigm Shift and Complexity Tolerance perspective to understand the “why” in each of the 4 adoption categories. This study further identifies 9 complexity tolerance strategies to help narrow the Deployment Gap but also shows that big data is not for everyone

Immutable Infrastructure Calls for Immutable Architecture

With the advent of cloud computing and the concept of immutable infrastructure, the scaling and deployment of applications has become significantly easier. This increases the possibility of “configuration drift” as an operations team manages this cluster of machines, both virtual and actual. In this paper we propose a revised view on configuration and architecture. We propose that software deployed on a public or private cloud should, to the furthest possible extent, be immutable and source controlled. This reduces configuration drift and ensures no configuration problems in production as a result of updates or changes. We will show an example of a software project deployed on Amazon Web Services with an immutable Jenkins setup which manages updating the whole cluster and is self-regenerating. We will also discuss how this lends itself naturally to interoperability between clouds, because of the infrastructure-agnostic nature of this approach

Architectural Tactics for Energy Efficiency: Review of the Literature and Research Roadmap

The energy consequences of software are rapidly growing: at the high-end, server farms consume enormous amounts of energy; at the low-end there is ever-increasing emphasis on battery-powered mobile and Internet-of-Things (IoT) devices with equally increasing complex usage scenarios. Conversely, there has been little attention to how software architectures can be designed for energy efficiency. While other software qualities—--think of performance or availability--—have been extensively studied, there is little research on how to reason about energy-consumption as a first-class citizen. We provide a basis for reasoning about design decisions for energy efficiency by deriving a kit of reusable architectural tactics derived from literature. We use the well-known open-search and snowballing methodologies to attain primary studies, and subsequently used thematic coding of such studies to identify recurrences and commonalities among the design strategies presented. The result of this process is a set of 10 architectural tactics for energy efficiency. These tactics provide a rational basis for architectural design and analysis for energy efficiency